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FIXED CLIENT IDENTIFICATION SYSTEM FOR 
POSITIVE IDENTIFICATION OF CLIENT TO SERVER 



CLAIM OF PRIORITY 

Tbis application claims priority under 35 USC 1 19(e) to U.S. Patent 
5 Application Serial No. 60/421 ,285 filed on October 25, 2002, the entire contents of 
which are incorporated by reference. 



Identification of a particular client computer system used for accessing a 
server is useful in secirre appUcations where positive identification is desirable. In the 
past, systems for identifying client computers, browser cookies, for example, have 
had less than satisfactory capabiUty of resisting tampering. 



A ClientID uniquely identifying a cUent machine is issued by the backend and 
stored on the cliCTit's machine upon first client appUcation connection to the backend. 
On all subsequent coimections, the client application retrieves the ClientID and sends 
it back to the backend. The ClientID mechanism includes features that make it very 

20 dijBBcult for the user to remove or change the ClientID once it is set. In particular, 

according to the invention, this is accomplished by having the client application store 
at least two different scrambled versions of the ClientID in two separate locations in 
the client machine. Upon subsequent connection to the backend, the cUent application 
attempts to retrieve and unscramble the values at the two locations. 

25 In the preferred embodiment, during the ChentID storage process, the backend 

generates a ClientID initially that contains a checksum and transmits it to the client 
application upon initial coimection to the backend. The cUent appUcation uses a first 
key to scramble the ClientID generating a first scrambled ClientID that is stored in the 
first predetermined location, for example the registry. A second key is used by the 
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client application to produce a second scrambled version of the CliOTtID that is stored 
in the second predetermined location, for example the system configuration file. 

Upon subsequent connection of the backend, a retrieval process is invoked in 
which the cUent appUcation retrieves the values at each location, unscrambles them 
5 using the respective keys, tests their checksirais for verification, and compares the 
unscrambled values. If the checksums are both correct and the unscrambled values 
match, the retrieved CUentID is transmitted to the backend. Otherwise, the client 
^Ucation sends an appropriate error code to the backend. 

The details of one or more embodiments of the invention are set forth in the 
10 accompanying drawings and the description below. Other features, objects, and 

advantages of the invention will be sqpparent from the description and drawings, and 
from the claims. 



DESCRIPTION OF DRAWINGS 

FIG 1 is a flow and block diagram of the ClientID storage process. 
1 5 FIG 2 is a flow diagram of the CUentID retrieval process. 

Like reference symbols in the various drawings indicate like elements. 

DETAILED DESCRIPTION 

CUentID is a special tag that xmiquely identifies the client machine. Initially, 
the CUentID is generated by the backend and stored on cUent*s machine upon first 
20 client application connection to the backend. On all subsequent connection, cUent 
^pUcation retrieves the CUentID and sends it back to the backend. Unlike browser 
cookies, the CUentID mechanism includes some special tamper-proof features that 
make it very difficult for the us&r to remove or change the CUentID once it is set 
Note: CUentID remains on the cUent's machine even after the client 
26 appUcation is uninstalled. CUentID installation/retrieval occurs as a part of the cUent 
appUcation startup process, as shown in FIG 1, described in more detail below. 

ClientID Storage Process 

CUentID is stored in at least two undisclosed locations on the cUent machine 
(for example, in the registry and system configuration file). As shown in FIG 1, the 
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Cli^tlD value is encrypted on tiie backend and contains a checksum. The client 
application has an ability to verify whether the checksum is correct. This makes 
ClientE) tampering much more diflBcult. In addition, prior to storing the ClientID in 
these two locations, the CUentID in each location is reversibly scrambled by the chent 
5 application with two diflferent keys. ITiis makes it impossible to find the second 
CUentID location even if someone learns the first location and performs a search 
based on a value stored in the first location. 

ClientID Retrieval Process 

Tn the begiiming of the ClientID retrieval process shown in FIG 2, the cUent 
10 appUcation attempts to retrieve and unscramble the values stored in both locations. 
Then it attempts to verify and compare these two values (if any were found). 

All possible retrieval outcomes are listed below. Only the first two can be 
considered '"normal", that is, should occur as a part of regular software usage. All 
15 other cases indicate that either someone is tampering with the ClientID mechanism or 
an Operating System malfimction/data cormption has occmred. 

a. ChentID is not foimd in either of the two locations. This would 
normally happen when the software is started for the first time on the client machine. 

20 Action: request a new ClientID from the backend. 

b. CUentID is found in both locations. The two values have a correct 
checksum and match each other. This should happen on the second and all subsequent 
client apphcation launches. Action: report retrieved CUentID value to the backend. 

c. CUentID is found in only one location. The value at that location has a 
25 correct checksum. Action: report retrieved ClientID to the backend along with error 

code #1 (see below for details) 

d. CUCTtID is foimd in both locations. Only one value has a correct 
checksum. Action: report retrieved CUentID fi:om the correct location to the backed 
along with error code #2 and a value firom the other location. 

30 e. CUentID is found in both locations. The two values have a correct 

checksum but do not match each other. Action: report retrieved ClientID value firom 
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the first location to the backend along with error code #3 and a value firom the second 
location. 

f. ClientID is foimd in both locations. Values from both locations fail the 
checksum verification. Action: request a new ClientID firom the backend, report error 
code #4 and values from both locations. 

g. ClientID is foxmd in only one location. The value at that location fails 
the checksum verification. Action: request a new ClientID from the backend, report 
error code #5 and a value from that location. 



10 In cases c. through g. an error code along with some optional data is reported 

to the backend. That information is logged on llie backend and, in conjunction with 
other data, like user IP, can be invaluable in detecting fraudulent activity. In cases c. 
through e. the error code and optional data are stored in the suppUed ClientID record. 
In cases f. and g. that information is stored in tihte newly generated ClientID record. 



A number of embodiments of the invention have been described. 
Nevertheless, it will be understood that various modifications may be made without 
departing from the spirit and scope of the invention. For example, more than two 
20 scrambled versions can be stored in respective locations. Accordingly, other 
embodiments are within the scope of the following claims. 
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WHAT IS CLAIMED IS: 

1 . A system for positively identifying a client macliine nmniiig a client application to 
a backend, comprising 

executing a ClientED storage process, including 
5 upon connection by the client application to the backend, generating a imique 

ClientID containing a checksum at the backend for the client machine, 
sending the CUentED to the client application, 

reversibly scrambling the CUentID with the cUent ^phcation at the chent 
machine and storing a first scrambled version of the CUentID at a first predetermined 
10 location on the cUent machine, and 

reversibly scrambling the ClientID with the cUent application at the chent 
machine and storing a second scrambled version different firom the first version of the 
ClientID at a second predetermined location on the client machine. 

2. The system of claim 1, fiirther comprising executing a ClientID retrieval process 
15 with the client appUcation when the client ^plication subsequently attempts to 

connect to the backend, including 

retrieving and unscrambling the values stored in botii locations using the first 
and second keys, 

running a checksimi operation on the unscrambled values to verify that each 
20 has the correct checksimi, and 

comparing the two unscrambled values to see whether they match. 

2. The system of claim 2, wherein the retrieval process executed by the cUent 
apphcation fiirther comprises 

if the two unscrambled values retrieved firom the two locations have the 
25 correct checksum and match each other, reporting the retrieved ClientID to the 

backend. 

3. The system of claim 3, wherein the retrieval process executed by the chent 
appUcation fiirther comprises 

if the two unscrambled values retrieved &om the two locations do not both 
30 have the correct checksum and match each other, reporting an error to the 
backend. 
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4. The system of claim 1, wherein the storage process further comprises encrypting 
the value of the newly generated ClientID at the backend and storing the 
encrypted vision of the CUentID on the backend in a ClientID record. 

5. The system of claim 1, wherein the storage process steps of scrambling use 
different first and second keys. 

6. The system of claim 1 , wherein one of the first and second locations is the registry. 

7. The system of claim 1 , wherein one of the first and second locations is the system 
configuration file. 

8. The system of claim 1, wherein the first and second locations are the registry and 
system configuration file. 
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